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(54) Network server for local and remote resources 

(57) A network server (14) permits clients (1 1) on 
the network to access one or more local resources man- 
aged by the network server and one or more renwte 
resources managed by one or more respective remote 
computers coupled to the network server. When a client 
desires to access any of the resources, the client first 
requests a session or log-on to the network server by 
supplying a valid account name and password. Either 
with the session establishment request or subsequently 
during the same session, the client requests a connec- 
tion or access to a resource. The client need not know 
the location of the resource or the computer (remote or 
network server) which manages the resource. The net- 
work server determines which computer manages the 
requested resource, tf the network server manages the 
resource, then the network server determines if the con- 
nection is available or provides the access as requested 
and responds to the client. TTien. if the client subse- 
quently requests a connection with or access to a 
resource managed by a remote computer, or if the orig- 
inal request was for a resource managed by the renK)te 
computer, the network server sends a session estat>- 
lishment request and connect or access request to the 
remote computer. The client need not send a separate 
session establishment request for the remote computer. 
If the remote computer grants the session, then the cli- 
ent can access the resource managed by the remote 
computer. 
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Description 

[0001] The invention relates generally to computer 
networks, and deals more particularly with a network 
server that permits a network client to access a local 5 
resource coupled directly to the network server and a 
remote resource coupled to a host computer. 
[0002] A previously known local area network (LAN) 
is used to interconnect multiple personal computers or 
work stations, called "clients', and a network server. The 
network server comprises a personal computer and a 
program which provides a variety of sen/ices to the cli- 
ents. For example, the server nnanages a local disk 
(DASD) and permits selected (or all) clients on the LAN 
to access the disk. Also, the server may provide access 
by LAN clients to a local printer that the server manages. 
To access the local disk, the client must first establish a 
session or "log-on" to the sen/er with a valid account 
and password and request a connection to the local 
disk. In response, the server validates the account and 
password, and grants the connection if available. Then, 
the client requests a remote file operation (e.g. open, 
read, write, close) and furnishes associated parame- 
ters. In response, the sen/er may copy (depending on 
the operation) the file from the local disk into RAM, and 
performs the operation requested by the client. If the file 
is updated, the server will copy the updated version back 
to the local disk, ovenwriting the previous version. 
[0003] A previously known IBM LANRES/VM compu- 
ter system comprises a LAN, a network server and a 
remote disk driver (with a remote disk) coupled to the 
network server. The remote disk driver is in the form of 
a System/370 host computer; however, the System/370 
computer is not used as a computer for service to the 
network sen/er, but merely as a disk driver for the remote 
disk. The network sen/er maintains a list of all resources 
that the network server can access, i.e. the local disk, 
the remote disk, all directories on the local disk and all 
directories on the remote disk, and a table or pointers 
to map each directory and file within the directory to the 
storage location on the corresponding disk. The clients 
do not know where the requested resource resides. To 
access any of the resources, a client on the L^N must 
establish a session with or log-on to the network server 
with a valid account and password, request a connec- 
tion to a named resource and provide a remote file op- 
eration/command and associated parameters. In re- 
sponse, the network server validates the account and 
password, determines the location of the named re- 
source and then translates the directory name into spe- 
cific addresses on the disk. If the file is located on the 
local disk, then the network server fetches the directory 
from the addresses and then performs the operation re- 
quested by the client. (The client may subsequently re- 
quest access to a file within the directory.) If the file is 
located on the remote disk, then the server provides to 
the remote disk driver the specific addresses of the di- 
rectory on the remote disk to be written to or read from 



and the write or read command. It should be noted that 
the network server cannot address the remote disk by 
a directory (or file) name, and the disk driver does not 
provide the security associated with a log-on require- 
ment. Also, because the data cannot be accessed by a 
directory (or file) name or as any discernible entity, it is 
not possible for another application program which ex- 
ecutes on the System/370 computer to access the di- 
rectory or file; this other application program does not 
know the location of the directory or file. Nevertheless, 
there is an important advantage to this LANRES/VM 
computer system. As noted above, the client need not 
know the actual location of the disk; the disk can be local 
to the network server or connected to the remote disk 
driver. In this respect, the sen/er is "transparent" to the 
client. 

[0004] In .Marshal), A.O.,et al.: ,On the Feasibility Of 
ISO FTAM-Based File Sen/ers To Implement A Heter- 
ogenous File System*, Computer Standards And Inter- 
faces, vol. 14,no.3, 1 Jan 1992, pages 191-208', a log- 
ical network model is described which has in each node 
a directory sen/er responsible for providing directory 
services', i.e. for locating a remote ressource, as e.g., a 
searched file. 

[0005] This yields to repeated requests to a plurality 
of node directory servers, if the requested file is not 
found at the first node requested. This is not an efficient 
way to search a particular file as, statistically a number 
of remote hosts are requested which cannot contribute 
to locate the searched file or network resource. 
[0006] In WO 91/02305 a method to access remote 
applications - not in the sense of ressources in general 
sense as e.g.. files in the present application - is de- 
scribed in which user identification or authentication 
does not play any relevant role when accessing said re- 
mote applications. 

[0007] Further, there is not provided any means for 
providing increased efficency of several subsequent ac- 
cesses to remote ressources, as e.g., files, because 
there is no need to authenticate the user and thus to 
hold such user information or session information in a 
central form on a network sen/er. 
[0008] A general object of the present invention is to 
provide a network server which permits a client on a net- 
work to access more efficiently a local resource man- 
aged by the network server and a remote resource man- 
aged by a host computer, which host computer provides 
host computer sen/ices relating to the remote resource. 
[0009] Another object of the present invention is to 
provide a network server of the foregoing type which 
permits a client to access both a local resource and a 
remote resource without knowing the location of either 
[0010] Still another object of the present invention is 
to provide a network sen/er of the foregoing type which 
permits an application program executing on the host 
computer to access the same directories and files on 
the remote resource that the clients can access. 
[001 1] A more specific object of the present invention 
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is to provide a network server of the foregoing type in 
which the host computer provides security for the re- 
mote resource. 

[001 2] Another specific object of the present invention 
is to provide a network server of the foregoing type s 
which permits a client to access remote resources man- 
aged by different host computers, and to do so efficient- 
ly. 

[0013] These and other objects are solved advanta- 
geously by the invention as claimed. 
[0014] The invention resides in a network sen/er that 
permits clients on the network to access one or more 
local resources managed by the network server and one 
or more remote resources managed by one or more re- 
spective remote computers coupled to the network serv- 
er 

[0015] When a client desires to access any of the re- 
sources, the client first requests a session or log-on to 
the network server by supplying an account name and/ 
or password. If the account name and/or password are 
valid, the network server establishes a session with the 
client. Either with the session establishment request or 
subsequently during the same session, the client re- 
quests a connection or access to a resource. The client 
need not know the location of the resource or the com- 
puter (remote or network server) which manages the re- 
source, and does not specify the location in the request. 
The network sen/er determines which computer man- 
ages the requested resource. If the network server man- 
ages the resource, then the network server determines 
if the connection is available or provides the access as 
requested and responds to the client. Then, if the client 
subsequently requests a connection with or access to a 
resource managed by a remote computer, or if the orig- 
inal request was for a resource managed by the remote 
computer, the network sen/er sends a session estab- 
lishment request and connect or access request to the 
remote computer The client need not send a separate 
session establishment request for the remote computer 
The remote computer then accepts or rejects the ses- 
sion establishment request based on security informa- 
tion stored in the remote computer for this client. If the 
session with the remote computer is established, then 
the client can access the resource managed by the re- 
mote computer For efficiency, the other remote comput- 
ers are not informed of the session or otherwise inter- 
rupted. 

[0016] According to one feature of the present Inven- 
tion, an applicatbn program executing on the host com- 
puter can also access the same remote resource man- 
aged by the host computer that the clients can access. 
[0017] The invention will be described In more detail 
by the following description in connection with embodi- 
ments shown in the drawing in which: 

Fig. 1 is a block diagram of a net work sen/er accord- 
ing to the present invention, a local DASD, a net- 
work of clients which can access the local DASD 
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via the network server, and remote computers cou- 
pled to the network server Fig. 1 also illustrates re- 
nnote DASDs which are managed by the remote 
computers and which the clients can access via the 
network server 

Figs. 2(a) and 2(b) are flow charts illustrating gen- 
eral operation of a back end sen/ice program within 
the network sen/er of Fig. 1 . 

Figs. 3(a-d) form a flow chart illustrating examples 
of operation of the network server and host comput- 
ers of Fig. 1 in response to specific requests by the 
clients. 

Figs. 4(a) and 4(b) form a flow chart illustrating other 
examples of operation of the network server and 
host computers of Fig. 1 In response to other spe- 
cific requests by the clients. 

Figs. 5(a) and 5(b) form a flow chart illustrating still 
other examples of operation of the network server 
and host computers of Fig. 1 in response to still oth- 
er specific requests by the clients. 

Fig. 6 is a block diagram illustrating a PCA adapter 
card within the network sen/er of Fig. 1 . 

Detailed Description of Embodiments 

[0018] Referring now to the drawings in detail wherein 
like reference numerals indicate like elements through- 
out the several views. Fig. 1 Illustrates a computer net- 
work generally designated 1 0 which includes many pre- 
viously known clients lla-z coupled together by a pre- 
viously known communication link 12 to form a LAN 1 3. 
and a network server 14 according to the present inven- 
tion. By way of example, each of the clients comprises 
a personal computer or a workstation which executes a 
DOS Lan Requestor, OS/2 LAN Requestor, PC LAN 
Program or LANMAN For DOS client program, and a 
Token-Ring or Ethernet adapter card to interface the 
personal computer or workstation to the other clients 
and the network server via the communication link. The 
network server 14 comprises a previously known per- 
sonal computer such as an IBM PS/2 personal computer 
with a processor 18 (although the network server could 
also execute in a multiprocessor environment), an OS/ 
2 operating system 20. a DASD controller 22 for local 
DASD 24, and a Token-Ring or Ethernet adapter card. 
For further details of the PS/2 computer, reference can 
be made to the following document which is available 
from International Business Machines Corp. in Mechan- 
icsburg, Pennsylvania: 'IBM PS/2 Reference Guide", 
G360-2669. The network server 1 4 also comprises a 
previously known parallel channel adapter (PCA) card 
28 to permit the network sen/er to communicate with a 
host computer 30 via an associated channel 32, and 
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with a host computer 34 via an associated channel 36. 
By way of exannple. each of the host computers com- 
prises a previously known IBM System/370 or Systenn/ 
390 computer and each of the channels comprises an 
IBM Block Multiplexor channel. The host computers 30 
and 34 provide basic computer functions such as secu- 
rity and nnanagement of respective DASDs 40 and 44. 
For further details of the host computers 30 and 34 and 
channels 32 and 36, reference can be made to the fol- 
lowing documents which are available from Internation- 
al Business Machines Corp. in Mechanicsburg, Penn- 
sylvania: • System/370 Principles of Operation" publica- 
tion number G/\22-7000. and "ES A/390 Principles of 
Operation" publication number SA22-7201. 
[0019] Figs. 2(a) and (b) illustrate operatran of net- 
work server 1 4 according to the present invention to per- 
mit any of the clients lla-z to access the local DASD 
24. remote DASD 40 and remote DASD 44. When a cli- 
ent 1 1 a-z is initiated or subsequently when the client de- 
sires to access a directory or file on local DASD 24, re- 
mote DASD 40 or remote DASD 42, the client requests 
a session with or log-on to the network server 14. This 
request involves registration and authentication of an 
account name for the client, and requires a valid account 
name, password and other parameters as follows: 
Client Maximum Buffer Size 
Actual Maximum Multiplexed Pending Requests 
Virtual Circuit Number - when a client establishes a com- 
munications link with a network server, that link is given 
a number to identify it uniquely This is that number 
Session Key 

Account Password Length Account Password 
Account Name 

Consumer Maximum Buffer Size 
[0020] At the time of making the session establish- 
ment request or subsequently, the client may request a 
connection to a resource such as a directory by name. 
However, the client could have requested a connection 
to other types of resources, for example, an entire data 
repository such as one of the DASDs, a part of a data 
repository such as a minidisk, a printer (not shown), or 
another data entity such as a file. The connect request 
is a request to determine if the resource is available and 
if the requestor is authorized to access the resource. 
The client need not know the location of the resource or 
which computer 14, 30 or 34 manages the resource. The 
connect request usually precedes another command to 
actually read from or write to the resource. By way of 
example, all requests from the clients use a sen/er mes- 
sage block (SMB) or Network File System (NFS) Re- 
mote Procedure Call (RPC) protocol, which are further 
defined in documents entitled "Microsoft Networks/ 
OpenNET File Sharing Protocol", Intel Part Number 
138446 Version 1.9, 04/21/87, Microsoft Corporation. 
Intel Corporation; "Microsoft Networks SMB FILE 
SHARING PROTOCOL EXTENSIONS: SMB File Shar- 
ing Protocol Extensions Version 2.0", Document Version 
3.2, 07/13/88. Microsoft Corporation; and "Microsoft 



Networks SMB FILE SHARING PROTOCOL EXTEN- 
SIONS: SMB File Sharing Protocol Extensions Version 
3.0", Document Version 1.09, 11/29/89, Microsoft Cor- 
poration for SMB Protocol, and Internet RFC 1057, Sun 
5 Microsystems, Inc., June 1988 for NFS Protocol. 
[0021] A network interface 52 within network sen/er 
14 receives the request(s), associates the request with 
the appropriate client and session, determines the cor- 
rect process to receive the request, and then passes the 
TO request(s) to a front end service program 53. The front 
end sen/ice program passes this request(s) (and all cli- 
ent requests), without change, to a back end service 
program 60. (The front end service program and back 
end service program are both executed by processor 1 8 
IS after being loaded or read from a magnetic disk or tape 
into RAM 103). When the back end service program re- 
ceives the request (step 104). the back end service pro- 
gram determines if the request includes a session es- 
tablishment request (decision block 106). If so, the back 
20 end sen/ice stores in a session establishment data table 
54 the foregoing information from the client request and 
the following information which the front end sen/ice and 
the back end service generate (step 110): 



[0022] Session Structure Pointer - when a client ses- 
sion 

establishment requests is received by a network sender, 
the network sen/er associates this request with a control 
block of information about that client. This field is the 
address of that control block. Once the session is es- 
tablished, the network server sets a bit to indicate that 
this session is active. 
Session Encryption Key Length 
Session Encryption Key 

Remote Client Name Length - the length of the remote 
client name. 

Remote Client Name - this is the address of a block of 
storage that contains the machine name of the client that 
has/is attempting to establish a session with this net- 
work server. This address comes from the session struc- 
ture. 



[0023] Account Name Length 
Session Next Pointer - next instance of this structure 
based on session structure pointer - linked list. 
Session Previous Pointer 

Structure Next Pointer - next instance of this structure 
for any session - linked list. 
Structure Previous Pointer 
Structure Flags 

[0024] This information forms a client control block. 
[0025] Next, the back end service determines if the 
request includes a connect request, and if so, is the re- 
source for which connection is requested stored within 
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a remote DASD (or other external device) managed by 
either host computer 30 or 34 (decision block 112). The 
latter determination Is made by reading a resource table 
56 to identify the location of the DASD or other external 
device that stores the file. If there is no such request to 
connect to resource managed by either remote DASD 
40 or 44. then the back end service returns the client 
request to the front end service for processing. The front 
end sen/ice then determines if the account and pass- 
word are valid by comparing them to lists of valid ac- 
counts and passwords, respectively. If the account and 
password are valid, the front end service establishes a 
session with the client by setting a flag in the session 
structure pointer field in the control blocks. Then the 
front end service notes the existence of the session in 
an active session table 57 and returns a session estab- 
lishment acknowledgement to the client via the network 
interface and to the back end service (step 116). If the 
request also includes a connect request for a resource 
managed by the network server such as a directory 
stored in local DASD 24, then the front end service also 
checks the status of the connection, and reports the out- 
come to the client. If the password is not valid, or if the 
session cannot be established for some other reason 
(such as a limit on the number of sessions allocated to 
each resource), then the front end sen/ice returns a ses- 
sion refusal message to the client (step 116). 
[0026] Referring again to decision block 112, if the cli- 
ent request includes a request to connect to a resource 
managed by remote computer 30 or remote computer 
34 such as remote DASD 40 or remote DASD 44, re- 
spectively, then the back end sen^ice passes the ses- 
sion establishment request to the front end service (step 
120), and waits for a return acknowledging session es- 
tablishment with the network server (step 1 22). The front 
end sen/ice then determines if the session can be es- 
tablished (i.e. valid account and password, no other 
problems), and sends the response to the back end 
service. If the session is not successfully established 
(decision block 123), then the back end sen/ice sends 
an error message to the client via the front end sen/ice, 
refusing the session (step 124). However, if the session 
is successfully established, then the back end service 
sends the entire client request including the session es- 
tablishment request and the connect request to the one 
host computer which manages the resource for which 
connection is requested (step 130), and waits for a re- 
sponse (step 132). It should be noted that the form of 
the session establishment request and connect request 
sent to the host computer by the network server in step 
1 30 can be the same as that sent to the network sen/er 
by the client. However, it may be necessary to provide 
a mapping between user/client ID, resource connection 
1 D and file 1 D between that provided by the network sen/- 
er and that required by the remote computer. When the 
response is received from the host computer indicating 
whether the session was established and the connec- 
tion is available, the back end sen^ice stores an identifier 



for this host computer in the client control block (step 
133), and passes the response to the front end service 
(step 134). then the front end service passes the re- 
sponse to the client via the network interface 52. The 
s form of the session establishment response originating 
from the host computer and sent to the client after step 
1 34 can be the same as that sent to the client after step 
116 when there was no connect request to either host 
computer. If it is not identical, the network server alters 
the format suitably. Consequently, the client does not 
know the origin of the session establishment response 
or connect response, and assumes that the client now 
has access to any resource available from the network 
server To support this assumption, the network server, 
as described below, will subsequently request session 
establishment on behalf of the client with any other re- 
mote computer connected to the network sen/er when 
and if the client requests access to a resource managed 
by this other remote computer. The client need not re- 
quest session establishment again during the course of 
the session that was just established after steps 1 20 and 
130. This makes the network sen/er transparent to the 
clients, yet there is no burden ever (for session estab- 
lishment) on any host computer that does not manage 
a resource for which the client requests a connection. 
[0027] Subsequently, the client sends a request to the 
network server to access a named resource (assume 
the one for which a connect request was previously 
sent). The client need not know the location of the re- 
source or computer which manages the resource, and 
does not specify the location in the request. The front 
end service receives the request via the network inter- 
face, and passes the request to the back end service 
(step 1 04). Because this request is a resource access 
request and not a session establishment request (deci- 
sion block 106), the back end sen/ice next determines 
if the named resource is managed by either remote com- 
puter 30 or 34 (decision block 140). This determination 
is made by reading the resource table 56. If the named 
resource is instead managed by network sen/er 14 (for 
example, stored on local DASD 24), then the back end 
service passes the request to the front end sen/ice for 
processing (step 116). For a read request, the front end 
sen/ice reads the directory from local DASD 24 into data 
buffer 69, and then sends the directory to the client for 
storage in the client's RAM. For a write request, the front 
end service writes the data supplied with the write com- 
mand into data buffer 60 and then into the directory with- 
in local DASD 24. Other types of requests are handled 
in an appropriate manner. 

[0028] Referring again to decision block 140, if the 
named resource is managed by either remote computer 
30 or 34 (for example, stored on either remote DASD 
40 or remote DASD 44). the back end sen/ice deter- 
mines that a session was previously established and is 
currently active for this client with the host computer that 
manages the requested resource (decision block 142). 
This determination is made by reading the active ses- 
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sion table 57. Then, the back end service sends the re- 
source access request to the host computer (step 130) 
and then warts for a response (step 1 32). It the resource 
access request is a read request, then the host compu- 
ter will read the resource from the remote DASD into 
host RAM, and send the resource to the data buffer 60. 
and the back end service will send the data to the client 
via the front end service (step 134). If the resource ac- 
cess request is a write request, the host computer will 
write the data into the remote DASD, and respond to the 
client via the front end service with an acknowledgement 
in step 134. 

[0029] The client can also send a request to connect 
to another resource which is managed by the (or any) 
other host computer. 

[0030] Referring again to decision block 1 42. if there 
is not yet a session established with this other host com- 
puter that manages the requested resource, then the 
back end service determines if session establishment 
data has been saved for this client by reading the ses- 
sion establishment data table 54 (decision block 148). 
If not, (which means that there is not an active session 
with the network sen/er), then the back end sen^ice re- 
sponds to the client via the front end sen^ice with an error 
signal and refuses connection to the host computer 
(step 124). (The client can now request a session es- 
tablishment, and the flow chart of Fig. 2 will proceed as 
described above for steps 104, 106, 110 etc.) 
[0031] Referring again to decision block 148, if the 
session establishment data has been saved for this cli- 
ent (meaning that there is currently an active session 
with at least the network server), the back end sen/ice 
builds a session establishment request based on the 
session establishment data stored in the table 54 and 
sends the request to this other host computer (step 1 52). 
It should be noted that in accordance with an object of 
the present invention, the client itself is not burdened 
with establishing a session with the host computer or 
even knowing that a host computer manages the re- 
quested resource. It should also be noted that the back 
end service establishes sessions only with those host 
computer(s) that manage resources for which connec- 
tion or access has been requested, and the other host 
computer(s) are not interrupted. This maximizes effi- 
ciency. 

[0032] After sending the session establishment re- 
quest, the back end sen/ice waits for a response (step 
156) from the host computer. The host computer will 
then determine if the session should be established 
based on the account name, password and other infor- 
mation, and respond with a session establishment ac- 
knowledgement or refusal to the back end service. If the 
session with this client has been established (decision 
block 170), then the back end sen^ice will send the re- 
source connection to the host computer (step 1 30), and 
then execute steps 132, 133 and 134 as described 
above. The client can then follow with a resource access 
request. Referring again to decision block 170, if the 



host computer refuses to establish the session, then the 
back end service will pass the error message and refus- 
al to the client via the front end sen/ice (step 124). 
[0033] Fig. 2()b illustrates another portion of the back 

5 end service program which handles requests to termi- 
nate sessions. The requests can originate from either a 
client lla-z or be initiated by administrative action on 
the network sender (or indirectly by administrative action 
from the remote computer(s)). and includes a session 

^0 structure pointer parameter. 

[0034] The front end service receives this request, 
passes this request to an entry point in the back end 
service program corresponding to step 200, and proc- 
esses the deleted session with the client by ending all 

75 work in progress by that client, and performing any 
needed cleanup. Then, the back end service reads the 
session establishment data table 54 to determine which 
of the network sen/er. host computer 30 and host com- 
puter 34 have established a session with the requesting 

20 client (step 202), If neither of the host computers 30 nor 
34 (nor any other host computer) has established a ses- 
sion with the requesting client (decision block 204), then 
the back end service returns control to the front end 
service (step 206), which terminates its processing of 

25 this request. However, if either of the host computers 30 
or 34 has established a session with the requesting cli- 
ent, then the back end service builds a session delete 
notification (step 208) and sends the notification to all 
host computers that have established a session with the 

30 requesting client (step 210). The session delete notifi- 
cation includes the host identifier parameter that was 
stored in step 1 33. 

[0035] The notified host computers proceed to delete 
the session by ending all work associated with the user 

55 and performing any needed cleanup, and then return ac- 
knowledgements to the back end sen/ice which is wait- 
ing (step 212). Then, the back end service returns con- 
trol to the front end service, which terminates its 
processing of this request. 

40 [0036] Figs. 3(a-d) illustrate operation of the network 
server 14 (including the back end service described 
above) and associated host computers 30 and 34 in re- 
sponding to five specific requests by one client 11a on 
network 1 3. In step 310, the client issues a bundled re- 

4S quest for session establishment and connection to a re- 
source such as a directory that happens to reside in local 
DASD 24. The front end service passes the request to 
the back end semce (step 312), the back end service 
stores the establishment data in step 110 and sends the 

so request to the front end service in step 116. Then the 
front end service establishes the session, processes the 
connect request, and notifies the back end service and 
the client of the session (step 314). Because the re- 
source is not managed by either remote computer 30 or 

55 34, the back end sen/ice does not attempt to establish 
a session with either remote computer 30 or 34. 
[0037] In step 320. the client subsequently issues a 
connect request for a resource such as a directory that 
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happens to reside on remote DASD 40 which is man- 
aged by host computer 30. The front end service passes 
the request to the back end service (step 322). and the 
back end service performs steps 1 52 and 1 56 described 
above in which the back end service requests that a ses- 
sion be established with host computer 30 and then 
waits for the response. This is necessary because the 
resource resides on remote DASD 40, and the session 
established in step 314 was confined to the network 
server The host computer establishes the session {step 
324), and then the back end service performs steps 1 30 
and 1 32 described above In which the back end service 
sends the connect request to the host computer and 
waits for the response. Then, the host computer proc- 
esses the connect request and responds to the back end 
service with the result (step 326). Then, the back end 
service sends the response to the client via the front end 
sen/ice (step 134). 

[0038] In step 330, the client subsequently issues a 
request to connect to a second resource that happens 
to reside also on remote DASD 40. The front end service 
passes the request to the back end sen/ice (step 332), 
and the back end sen/ice sends the connect request to 
the host computer 30 (step 130). Because there is al- 
ready a session established with host computer 30 for 
client 11a, it is not necessary to establish another ses- 
sion with host computer 30. Then the host computer 30 
processes the connect request (step 334), and then the 
back end sen/ice returns the response to the client via 
the front end service (steps 1 32 and 1 34). 
[0039] In step 340, the client subsequently issues a 
request to connect to a resource that happens to reside 
on the other remote DASD 44 which is managed by host 
computer 34. The front end service passes the request 
to the back end sen/ice (step 342), and the back end 
service executes steps 152 and 156 described above in 
which the back end sen/ice requests a session with host 
computer 34 for client 1 1 a and then waits for a response. 
Then the host computer 34 establishes the session with 
the client 11a and responds with an acknowledgement 
(step 344). Such a session is necessary because the 
resource resides on remote DASD 44, and the sessions 
established earlier in steps 31 3 and 324 did not involve 
host computer 34. Then, the back end service passes 
the connect request to the host computer 34 and waits 
for a response (steps 130 and 132), the host computer 
34 processes the request and returns a response (step 
346). In step 1 34, the back end service fonwards the re- 
sponse to the client via the front end service. It should 
be noted that the session with host computer 34 was not 
established until the client requested a connection to 
DASD 44; this optimizes efficiency. 
[0040] In accordance with one object of the invention, 
an application program executing on the host computer 
30 can access the same remote resource such as a di- 
rectory on DASD 40 that the client can access. This is 
illustrated by step 348 in which a user application pro- 
gram 349 executing on host computer 30 (or coupled to 



12 

the host computer 30 via a communication facility not 
shown) nnakes a request to the host processor to link 
the application program to a minidisk portion of DASD 
40. This linkage provides the application program with 

s access by resource name to alt the resources on the 
minidisk including the directory that was accessed by 
the client. Thus, the application program can now read 
from or write to the directory and any file therein stored 
on the minidisk by open, read, write or delete, close and 

10 other commands. 

[0041] In step 350, the client subsequently Issues a 
request to terminate the session. It should be noted that 
the client need not know that sessions were established 
also with host computers 30 and 34. The front end sen/- 

^5 Ice passes the request to the back end service (step 
352), and the back end service executes steps 200-206 
described above In which the back end service deter- 
mines which host computers have an active session 
with this client, builds a session termination notification 

20 and sends it to each host computer which has an active 
session for this client. In this example, host computers 
30 and 34 currently have an active session with this cli- 
ent. Then, the host computers 30 and 34 terminate their 
sessions with this client 11a (steps 354 and 356). 

25 [0042] Figs, 4(a) and (b) illustrate operation of the net- 
work server 14 (including the back end sen^ice de- 
scribed above) and associated host computer 30 in re- 
sponding to three other specific requests by one client 
1 1 a on network 1 2. In step 41 0, client 1 1 b. Issues a bun- 

30 died request for session establishment and a connec- 
tion to a resource that happens to reside on DASD 40 
which is managed by host computer 30. The front end 
service passes the request to the back end service (step 
412), and the back end service saves the session es- 

55 tabllshment data and returns control to the front end 
sen/Ice (steps 110 and 120). Then the front end service 
establishes the session, transfers control to the back 
end service and notifies the back end service that the 
session has been established (step 414). Next, the back 

40 end service executes steps 122 and 130 described 
above in which the back end service requests a session 
with host computer 30 for client 1 1 b, and then host com- 
puter 30 establishes the session with client 11b, proc- 
esses the connect request, and returns the result of the 

45 connect request processing to the back end service 
(step 41 6). Then, the back end service retums the result 
to the client via the front end service (step 1 34). 
[0043] In step 420, the client 1 1 b Issues a connect re- 
quest within the same session that was established In 

50 step 414 for a resource that happens to reside within 
local DASD 24. The front end service passes the re- 
quests to the back end service (step 422), and the back 
end sen/ice returns the request to the front end service 
because the request involves only local DASD 24 (step 

55 116 described above). Then, the front end sen/ice proc- 
esses the connect request (step 424). It is not necessary 
to establish any other sessions in view of the existing 
session with network server 14 for client lib. 
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[0044] In step 430, the client 11b issues a request to 
terminate the session that was established in step 41 4, 
and the front end service passes the request to the back 
end service (step 432). Then, the back end service de- 
termines that a session currently exists for this client 
with host computer 30, builds a session termination no- 
tification based on the ciient request, and sends the no- 
tification to host computer 30 (steps 202. 208 and 210), 
It is not necessary to send the notification to host com- 
puter 34 because no session was previously estab- 
lished for client 11b on account of the requests made in 
Fig. 4 (a) and (b). In step 434, the host computer 30 
terminates the session with client 11b. 
[0045] Figs. 5(a) and (b) illustrate operation of the net- 
work sen/er 14 (including the back end sen/ice de- 
scribed above) and associated host computers 30 and 
34 in responding to three other specific requests by one 
client 11c on network 12. In step 510, client 11c issues 
a session establishment request to network server The 
front end service passes the request to the back end 
service (step 512). and the back end sen/ice saves the 
session establishment data and returns the request to 
the front end service (steps 1 1 0 and 1 1 6). Because there 
is no request to connect to a resource on either remote 
DASD (or any resource), it is not necessary for the back 
end service to pass any request to either host computer 
30 or 34. In step 514, the front end service establishes 
the session with client 11c, notifies the back end service 
of the session establishment, and returns a session es- 
tablishment notification to the client 11c. 
[0046] In step 520, the client 1 1 c sends a connect re- 
quest to the network server for a resource that happens 
to reside on DASD 44 which is managed by host com- 
puter 34. The front end service passes the request to 
the back end service (step 524), and the back end serv- 
ice builds a session establishment request based on the 
data stored in the session establishment data table, and 
sends the request to host computer 34 (steps 152 and 
1 56). In step 524, host computer 34 establishes the ses- 
sion with client 11c and retums an acknowledgement to 
the session establishment request. Because the con- 
nect request does not involve host computer 30, the cli- 
ent requests are not sent to host computer 30 and host 
computer 30 is not interrupted in any way After receiv- 
ing the response from the host computer 34. the back 
end service passes the connect request to host compu- 
ter 34 and waits for a response (steps 130 and 132). 
The host computer 34 processes the connect request 
and returns a response (step 524). The back end sen/ice 
forwards the response to the client via the front end serv- 
ice (step 134). 

[0047] In step 530, the client 11c issues a request to 
the network server to terminate the session. The front 
end service passes the request to the back end service 
(step 532), and the back end service determines that 
host computer 30 has established a session with the cli- 
ent 11c, builds a session termination notification and 
sends it to the host computer 34. Because the host com- 



puter 30 was never involved with the client request of 
Fig. 5, the back end service does not send the session 
termination notification to host computer 30. In step 534, 
the host computer 34 terminates the session with client 

5 11c. 

[0048] The following is a detailed description of the 
channels 32 and 36, and the PCAcard 28, although the 
present invention does not depend on the specific type 
of communication facilities which are utilized. 

10 [0049] Each of the host computers 630 and 634 in- 
cludes a host processor 670 and 674, a main memory 
680 and 684, a "Blue" bus 690 and 694 servicing the 
host processor, the main memory, the Block Multiplexor 
channel 632 and 636, and DASD controllers 697 and 

IS 699 respectfully. DASD controllers 697 and 699 control 
the reading from and writing to the remote DASD 640 
and 644 respectively, and are well known in the art. 
[0050] Each channel includes a host port, a buffer 
memory to temporarily store all data transferred be- 

20 tween the Blue bus and the host port, and a channel 
processor to control the data transfer from the main 
memory to the host port via the buffer memory. The 
channel relieves the host processor of the burden of 
transferring data between the main memory of the host 

25 computer and the host port, and once called by the host 
processor, is independent of the host processor. 
[0051] To initiate a data transfer from the main mem- 
ory to the host port, the host processor (under the direc- 
tion of a host control program) builds a channel program 

30 including a sequence of channel command words 
(CCWs), and stores a channel address word at a pre- 
determined location. The channel address word points 
to the first CCW in the channel program. Each CCW in- 
cludes a command such as read or write, a byte length 

35 indicating the length of data to be read or written, and a 
pointer to the first location in main memory to store the 
data to be read in the case of a read CCW, or the first 
location of the data to be written in the case of a write 
CCW. The, the host processor issues a Start I/O com- 

40 mand which addresses the target device, in this case, 
the channel. 

[0052] The channel processor receives the Start I/O 
command and fetches the first CCW. Pursuant to a sin- 
gle write CCW, the channel processor fetches a block 

45 of data from (host) main memory at a location indicated 
by the pointer and copies the data into the channel buffer 
memory. Next, the channel processor dispatches anoth- 
er task which executes on the channel processor to be- 
gin the transfer to the RCA card of the block of data that 

50 was recently copied into the channel buffer memory. 
Then, the channel processor processes subsequent 
write CCWs, if any, by fetching the corresponding blocks 
of data from the main memory and copying the data into 
the channel buffer memory. 

55 [0053] The channel is corrected to the PCA card 628 
by an IBM Bus and Tag cable. The Bus and Tag cable 
includes many parallel coaxial conductors to transmit 
data, address and control signals in parallel. 
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[0054] As illustrated in Fig. 6, the PCA card includes 
an Intel 80C186 nnicroprocessor ('PCA processor") 642 
and a shared RAM 44. The PCA processor 42 as well 
as the PS/2 processor 618 and channel state machine 
48 (within the PCA card) can all directly access shared 
RAM 44 (with permission by arbiter 60). Shared RAM 
44 includes a communication area for communication 
between the PS/2 processor 618 executing PCA driver 
code 630 and the PCA processor 642, and the transmit 
and receive data buffers to temporarily store all data 
transferred between a Micro Channel (R) bus associat- 
ed with the PS/2 processor and the channel, a multiplex- 
or 47 is located between shared RAM 44 and the Micro 
Channel (R) bus control logic 45 provides hand-shaking 
for the Micro Channel (R) bus and address latching for 
addresses supplied to the MicroChannel (R) bus. Chan- 
nel state machine 48 provides channel protocol and 
control sequences for communication with the channel. 
Arbiter 50 arbitrates access to shared RAM 44 between 
the Micro channel (R) bus, the channel state machine 
48, and the PCA processor 42. A program RAM 56 
stores PCA processor microcode, and channel status 
and device information, and forms a command FIFO 
and a status FIFO described below. 
[0055] Channel interface logic or renriote port 57 in- 
cludes drivers and receivers for interlacing to channel 
bus and tag lines. Micro Channel (R) interface logic 41 
includes the multiplexer 47 and latches for interfacing to 
address and data lines on the Micro Channel (R) bus. 
[0056] The following procedure is used to transfer da- 
ta from the data buffer 669 of the PS/2 processor to the 
RAM 680 or 684 of the host processor with initiation from 
the PS/2 processor. First, the PS/2 processor obtains 
access to RAM 44 with permission from arbiter 50 in or- 
der to read a list in RAM 44 of available transmit data 
buffers. Neither the Systenn/370 processor nor the chan- 
nel participates in the decision where to store the data 
in RAM 44. Then, the PS/2 processor writes the data 
into an available data buffer in RAM 44. Next, the PS/2 
processor sends a write command message with device 
address, buffer address and transfer size to the PCA 
processor 42 via the communication area in the shared 
RAM. The PCA processor processes the write com- 
mand by setting up control parameters, i.e. attention sta- 
tus, buffer address, and transfer size in the program 
RAM table. The PCA processor then writes the device 
address corresponding to the channel into the com- 
mand FIFO. The channel state machine 48 reads out 
the device address from the command FIFO and sends 
the attention status to the channel. The channel then 
interrogates the write command pending on the PCA 
card. Because of the channel protocol, the PCA will not 
send the data until a matching (read) command is re- 
ceived from the channel. 

[0057] The channel subsequently responds to the 
write command from the PS/2 processor with a read 
command. The channel state machine matches the 
channel read command with the PS/2 write command 



and notifies the channel state machine of the match. 
Then, the channel state machine sets up the data buffer 
addresses and length count and controls the data trans- 
fer from the RAM 44 to the channel. Upon completion 
s of the data transfer to the channel, the channel state 
machine writes an entry in the status FIFO to notify the 
PCA processor that the write operation has been com- 
pleted. 

[0058] The following procedure is used to transfer da- 

10 ta from the data buffer 669 of the PS/2 processor to the 
RAM 680 or 684 of the host processor with initiation by 
the host processor. The host processor builds a channel 
program which includes a read CCW, and issues the 
Start I/O command to the channel. The channel fetches 

'5 the read CCW, and sends a read command to the PCA 
card. Assuming that data is not waiting in the PCA buffer 
for transmission to the channel, the channel state ma- 
chines 48 will return "command retry status" to notify the 
host processor that the data is not immediately availa- 

20 ble. After returning the command retry status, the chan- 
nel state machine 48 writes an entry in the status FIFO 
to notify the PCA processor of the read command re- 
ceived from the channel. In response, the PCA proces- 
sor notifies the PS/2 processor about the read com- 

2S mand. When the PS/2 processor has data to send to the 
host processor, the PS/2 identifies an available buffer in 
RAM 44, and writes the data into the available buffer. 
Then, the PS/2 processor writes a message into the 
shared communication area of RAM 44 to notify the PCA 

30, processor of the existence and locatbn of the data. In 
response, the PCA processor nnakes an entry into the 
command FIFO to notify the channel state machine of 
the write command from the PS/2 processor and the tar- 
get device address. The channel state machine sends 

35 a "data ready" status signal to the channel, and the 
channel responds with the read command again. Final- 
ly, the channel state machine 48 controls the data trans- 
fer from the transmit buffer in RAM 44 to the channel 
buffer. 

40 [0059] The following procedure is used to transfer da- 
ta from the RAM 680 or 684 of the channel to the data 
buffer 669 of the PS/2 processor with initiation from the 
host processor. The host processor builds a channel 
program which includes a write CCW, and issues the 

4S start I/O to the channel. The channel fetches the write 
CCW and corresponding data from the main memory, 
and stores the data in the channel data buffer. Then, the 
channel sends to the PCA card a corresponding write 
command. The channel state machine 48 obtains a data 

so buffer from the shared RAM 44 by reading the list of 
available data buffers. (In the PCA system, it is not nec- 
essary to interrupt the PS/2 processor at this time.) Nei- 
ther the System/370 processor nor the channel partici- 
pates in the decision where to store the data in RAM 44. 

ss Then the channel state nnachine 48 controls the data 
transfer from the channel to the shared "RAM with the 
channel responding to control sequences established 
by the state machine 48. Upon completion, the channel 
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state machine writes an entry into the status FIFO to 
notify the PCA processor about the receipt of the data 
from the channel and the location and length of the data 
in he receive buffer in RAM 44. The PCA processor 
reads out the entry from the status FIFO and then noti- 
fies the PS/2 processor via the communication area in 
the shared RAM. The PS/2 processor finally moves the 
data from the shared RAM into the PS/2 system RAM. 
[0060] The PS/2 processor can also initiate transfer 
of data from RAM 680 or 684 of the host processor to 
the data buffer 669 of the PS/2 processor. First, the PS/ 
2 processor obtains access to RAM 44 (with permission 
from arbiter 50) in order to read the list of available re- 
ceive data buffers. Then, the PS/2 processor sends a 
read command message with device address, buffer ad- 
dress and transfer size to the PCA processor 42 via the 
communication area in the shared RAM. The PCA proc- 
essor processes the read command by setting up con- 
trol parameters, i.e. attention status, buffer address, and 
transfer size, in the program RAM table. The PCA proc- 
essor then writes the device address corresponding to 
the channel into the command FIFO. The channel state 
machine 48 reads out the device address from the chan- 
nel FIFO and sends the attention status to the channel. 
The channel then interrogates the read command pend- 
ing on the PCA card. The channel subsequently re- 
sponds to the read command with a write command. 
The channel state machine matches the channel write 
command with the PS/2 read command. Then, the 
channel state machine sets up the data buffer address- 
es and length count and control the data transfer from 
the channel to the RAM 44. Upon completion of the data 
transfer from the channel, the channel state machine 
writes an entry in the status Fl FO to notify the PCA proc- 
essor that the read operation has been completed. 
[0061] Instead of using the PCA driver 630, PCA card 
28 and channels 32 and 36, the following commercially 
available software and hardware can be used to provide 
two alternate configurations. An IBM Personal Worksta- 
tion Communication Services/VM program can execute 
on the processor 18 to interlace processor 18 and data 
buffer 69 to an IBM Token-Ring Network 16/4 Adapter/ 
A (IBM part number 74F9410) which is located at the 
network sen/er. The Token-Ring Network 16/4 Adapter/ 
A is coupled toan IBM Integrated LAN adapter (IBM part 
number 61 34 for an ES/9000 type of host computer and 
part number 6034 for a 9370 type of host computer) 
which is located at the host computer and interlaces to 
the host processor. 

[0062] Alternately, the IBM VM Personal Workstation 
Communication Services (PWSCS) program executes 
on the processor 18 to interface processor 18 and data 
buffer 69 to an IBM Channel Emulator/A card (IBM part 
number 1 674899) which is located at the network serv- 
er AN IBM 3088 multisystem channel communication 
unit interconnects the Channel Emulator/A card to the 
Block Multiplexor channel of the host computer Other 
connectivities are also available with PWSCS program. 



[0063] Based on the foregoing, a network server ac- 
cording to the present invention has been disclosed. 
However, numerous modifications and substitutions can 
be made without deviating from the scope of the present 

5 invention. For example, different type of networks, i.e. 
different clients and different network communication 
links, can be served by the network server, and the net- 
work server can interface to different types of remote 
computers. Also, the files can be stored on other types 

10 of repositories. Therefore, the invention has been dis- 
closed by way of illustration and not limitation, and ref- 
erence should be made to the following claims to deter- 
mine the scope of the present invention. 



Clalma 

1 . A method for managing access by clients (1 1 a- 1 1 z) 
in a network to one or more local resources (24) 
20 managed by a network server (14) and one or more 
remote resources (40,44) managed by one or more 
respective remote computers (30,34) logically and/ 
or physically coupled to the network server, said 
method comprising the steps of: 

25 

sending (310) from one of said clients to said 
network server a request to establish a sessron 
and a request to connect to or access a first 
resource (24), wherein said requests are pref- 
^0 erably provided by a single request, said ses- 

sion establishment request including an ac- 
count name and password for said one client; 

in response to the session establishment re- 
35 quest (1 23). establishing by said network sen/- 

er a session between said network sen/er and 
said client, and storing (133) said account 
name and password; 

40 in response to the request to connect to or ac- 

cess said first resource, determining that said 
first resource is managed by said network send- 
er, and determining if said connection is avail- 
able to said first resource (24); 

45 

subsequently, sending (310) from said one cli- 
ent to said network server a request to connect 
to or access a second resource (40,44); and 

so in response to said subsequent request to con- 

nect to or access said second resource (40,44), 
determining (140) by said network server that 
one of said remote computers (30,34) manages 
said second resource, sending (152) a request 
5$ by said network server to said one remote com- 

puter to establish a session with said one re- 
mote computer, said request including said 
stored account name and password, and send- 
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determining (202,204) by said network server 
that said one remote computer is involved in 
said session; 

sending (352) by said network server to said 
one remote computer a request to terminate 
said session requested by said network sen/er; 
and 

terminating (208) by said network server the 
session between said network server and said 
one client. 

Method as set forth in claim 1 or one of the claims 
2 to 4, further comprising the steps of: 

after said subsequent request, making a re- 
quest by another application program execut- 



10 6. 



ing a request by said network server to said one 
remote computer to connect to or access said 
second named resource. 

Method as set forth in claim 1 further comprising the 
subsequent steps of: 

sending (340) from said one client ( 11 a- 11 z) to 
said network server (14) a request to connect 
to or access a third resource; 

determining by said network server that anoth- 
er one of said remote computers manages said 
third resource; and 

sending (130) by said network sen/er to said 
other remote computer a request to establish a 
session, said session establishment request in- 
cluding said stored account name and pass- 
word, and a request to connect to or access 
said third resource. 

Method as set forth in claim 1 or 2 further comprising 
the steps of: 

validating (324, 344) by said one remote com- 
puter said account name and password includ- 
ed in said session establishment request, and 

establishing (326,334, 341 ) by said one remote 
computer said session requested by said net- 
work server. 



4. Method as set forth in claim 3 further comprising the 
steps of: 5^ 

sending from said one client (11a-11z) to said 
network server (1 4) a request to terminate said 
session; 
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ing within said one remote computer to access 
said second resource (40,44); and 

pursuant to said application program request 
by said other application program, providing ac- 
cess by said one remote computer (30,34) to 
said other application program to said second 
resource. 

Method as set forth in claim 1 or one of the claims 
2 to 5, wherein the subsequent connect or access 
request sent (1 40) by said one client to said network 
server specifies said second resource by name, but 
does not specify said one remote computer or loca- 
tion of said second resource. 

A method for managing access by clients (11a-11z) 
in a network to a local resource (24) managed by a 
network server (14) and one or more remote re- 
sources (40,44) managed by one or more respec- 
tive remote computers (30,34) logically and/or 
physically coupled to the network server, said meth- 
od comprising the steps of: 

sending (310) from one of said clients to said 
network server a request to establish a session 
and a request to connect to or access a first 
resource (40,44), wherein said requests are 
preferably provided by a single request, said 
session establishment request including an ac- 
count name and a password for said one client; 

in response to the session establishment re- 
quest (123), establishing by said network serv- 
er a session with said network sen/er, and stor- 
ing (1 33) said account name and password; 

in response to the connect or access request, 
determining that one of said remote computers 
manages (30,34) said first resource (40,44), 
sending (1 52) a request by said network sen/er 
to said one remote computer to establish a ses- 
sion with said one remote computer, said re- 
quest including said stored account name and 
password, and sending a request by said net- 
work server to said remote computer to connect 
to or access said first resource; 

subsequently, sending (310) from said one cli- 
ent to said network server a request to connect 
to or access a second resource; and 

in response to said subsequent request, deter- 
mining (1 40) that said network server manages 
said second resource, and determining wheth- 
er said second resource is available. 



8. Method as set forth in claim 7 further comprising the 
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step of establishing said session with said one re- 
nnote computer by said one renrtote computer vali- 
dating (324) said account name and password, in 
response to said session establishment request 
(152) from said network server 

9. A network sen/er (14) for managing access by cli- 
ents (lla-11 z) in a network to one or more local re- 
sources (24) managed by the network server and 
one or more remote resources (40,44) managed by 
one or more respective remote computers (30,34) 
logically and/or physically coupled to the network 
server, said network server comprising: 

means (52) for receiving from one of said cli- 
ents on said network a request to establish a 
session and a request to connect to or access 
a first resource, wherein said requests are pref- 
erably provided by a single request, the session 
establishment request including an account 
name and password for said one client; 

means (53,54) responsive to the session estab- 
lishment request, for establishing a session be- 
tween said network server and said one client, 
and storing said account name and password; 

means (56), responsive to the request to con- 
nect to or access said first resource, for deter- 
mining that said first resource is managed by 
said network server, and determining if said 
connection is available to said first resource; 
and 

means (56,60), responsive to a subsequent re- 
quest from said one client to connect to or ac- 
cess a second resource, tor determining that 
one of said remote computers manages said 
second resource, sending a request to said one 
remote computer to establish a session with 
said one remote computer, said request includ- 
ing said stored account name and password, 
and sending a request to said one remote com- 
puter to connect to or access said second re- 
source. 

10. Network server as set forth in claim 9 wherein; 



said third resource. 

11. Network server as set forth in claim 9 or 10 further 
comprising: 

5 

means, responsive to a request from said one 
client to terminate said session, for determining 
that said one remote computer is involved in 
said session; 

70 

means (60) for sending to said one remote 
computer a request to terminate said session 
requested by said network server; and 

75 means for terminating the session between 

said network server and said one client. 

12. Network sen/er as set forth in claim 9, 10 or 11 
wherein the subsequent connect or access request 

20 sent by said one client to said network server spec- 
ifies said second resource by name, but does not 
specify said one remote computer or a location of 
the resource managed said one remote computer. 

25 13. A network server (14) for managing access by cli- 
ents (11 a-11 z) in a network to a local resource (24) 
managed by the network server and one or more 
remote resources (40,44) managed by one or more 
respective remote computers (30, 34) coupled to 

30 the network sen/er, said network server comprising: 

means (52,53) for receiving from one of said 
clients on said network a request to establish a 
session and a request to connect to or access 
35 a first resource, the sessbn establishment re- 

quest including an account name and a pass- 
word for said one client; 

means (54,60), responsive to the session es- 
40 tablishment request, for establishing a session 

with said network server, and storing said ac- 
count name and password; 



means (56), responsive to the connect or ac- 
45 cess request, for determining that one of said 

remote computers manages said first resource, 
sending a request to said one remote computer 
to establish a session with said one remote 
computer, said request including said stored 
so account name and password, and sending a re- 

quest to said remote computer to connect to or 
access said first resource; and 

means (56), responsive to a subsequent re- 
55 quest to connect to or access a second re- 

source, for determining that said network serv- 
er manages said second resource, and deter- 
mining whether said second resource is avail- 



70 



75 



35 



the determining means (56) is responsive to an- 
other request from said one client to connect to 
or access a third resource to determine that an- 
other one of said remote computers manages 
said third resource; and 
the sending means (60) sends to said other re- 
mote computer a request to establish a ses- 
sion, said session establishment request in- 
cluding said stored account name and pass- 
word, and a request to connect to or access 
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able. 

14, A computer program product for managing access 
by clients (11 a-11 z) in a network to one or more local 
resources (24) managed by the network sen/er (1 4) 
and one or more remote resources (40,44) man- 
aged by one or more respective remote computers 
(30.34) logically and/or physically coupled to the 
network server, said computer program product 
comprising: 

a computer readable medium; 

a first program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to receive from one of said client or said 
network a request to establish a session and a 
request to connect to or access a first resource, 
the session establishment request including an 
account name and password for said one client; 

second program instruction means, recorded 
on said medium, for instructing a computer 
processor to respond to the session establish- 
ment request by establishing a session be- 
tween said network sender and said client, and 
storing said account name and password; 

third program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to the request to connect to 
or access said first resource, by determining 
that said first resource is managed by said net- 
work server, and determining if said connection 
is available to said first resource; and 

fourth program instruction means, recorded on 
said medium, for Instructing a computer proc- 
essor to respond to a subsequent request from 
said one client to connect to or access a second 
resource, by determining that one of said re- 
mote computers manages said second re- 
source, sending a request to said one remote 
computer to establish a session with said one 
remote computer, said request including said 
stored account name and password, and send- 
ing a request to said one remote computer to 
connect to or access said second resource; and 

wherein each of said program instruction 
means is executable by the associated compu- 
ter processor. 

15. Computer program product as set forth in claim 14 
wherein 

the third program instruction means is respon- 
sive to another request from said one client to 



connect to or access a third resource by in- 
structing a computer processor to determine 
that another one of said remote computers 
manages said third resource; and 

5 

the fourth program instruction means instructs 
a computer processor to send to said other re- 
mote computer a request to establish a ses- 
sion, said session establishment request in- 
10 eluding said stored account name and pass- 

word, and a request to connect to or access 
said third resource. 

16. Computer program product as set forth in claim 14 
IS or 1 5 further comprising: 

fifth program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to a request from said one cli- 
20 ent to terminate said session, to determine that 

said one remote computer is involved in said 
session; 

sixth program instruction means, recorded on 
2S said medium, for instructing a computer proc- 

essor to send to said one remote computer a 
request to terminate said sessbn requested by 
said network server; and 

30 seventh program instruction means, recorded 

on said medium, for instructing a computer 
processor to terminate the session between 
said network server and said one client; and 
wherein said fifth, sixth and seventh program 

35 instruction means are executable by the asso- 

ciated computer processor. 

17. Computer program product as set forth in claim 1 4, 
1 5 or 1 6 wherein the subsequent connect or access 

40 request sent by said one client specifies said sec- 
ond resource by name, but does not specify sak) 
one remote computer or an address of the resource 
managed said one remote computer. 

45 18. A computer program product for managing access 
by clients in a network to a local resource managed 
by the network server and one or more remote re- 
sources managed by one or more respective re- 
mote computers coupled to the network server, sakJ 

so computer program product comprising: 

first program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to receive from one of said clients on said 
ss network a request to establish a session and a 

request to connect to or access a first resource, 
the session establishment request including an 
account name and password for said one client; 
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second program instruction means, recorded 
on said medium, for instructing a computer 
processor to respond to the session establish- 
ment request by establishing a session with 
said network server, and storing said account s 
name and password; 

third program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to the connect or access re- fo 
quest by determining that one of said remote 
computers manages said first resource, send- 
ing a request to said one remote computer to 
establish a session with said one remote com- 
puter, said request including said stored ac- 
count name and password, and sending a re- 
quest to said remote computer to connect to or 
access said first resource; and 

fourth program instruction means, recorded on 20 
said medium, for instructing a computer proc- 
essor to respond to a subsequent request to 
connect to or access a second resource by de- 
termining that said network server manages 
said second resource, and determining wheth- 2S 
er said second resource is available; and 
wherein 

each of said program instruction means is ex- 
ecutable by the associated computer proces- 50 
sor. 

PatentansprOche 

35 

1 . Ein Verfahren zum Venwalten des Zugriffs durch Cli- 
ents (11 a-1 1 z) in einem Netzwerk auf ein oder meh- 
rere lokale Betriebsmittel (24), die von einem Netz- 
werk-Server (14) venwaltet werden, und ein oder 
mehrere Fembetriebsmittel (40. 44), die von einem 40 
Oder mehreren entsprechenden Fernrechnem (30, 
34) ven/valtet werden, logtsch und/oder physika- 
lisch gekoppett an den Netzwerk-Sen/er, wobei das 
Verfahren die folgenden Schritte umfa3t: 

45 

Senden (310), von einem der Clients an den 
Netzwerk-Server, einer Anforderung zum Auf- 
bau einer Sitzung, und einer Anforderung zum 
Verbinden mit, oder Zugreifen auf, ein erstes 
Betriebsmittel (24), wobei diese Anforderungen so 
vorzugsweise durch eine einzige Anforderung 
vorgesehen sind, und diese Sitzungsaufbau- 
Anforderung einen Account-Namen und ein 
Pa3wort fur den betreffenden Client enthalt; 

55 

als Reaktion auf die Sitzungsaufbauanforde- 
rung (1 23) Aufbau einer Sitzung zwischen dem 
Netzwerk-Server und dem Client durch den 



Netzwerk-Server, und Speichern (1 33) des Ac- 
count-Namens und des Pa3worts; 

als Reaktion auf die Anforderung zum Verbin- 
den mit, Oder Zugreifen auf das erste Betriebs- 
element, Bestimmen, da3 das erste Betriebs- 
element vom Netzwerk-Server venvaltet wird, 
und Bestimmen, ob die Verbindung zum ersten 
Betriebselement (24) zur Verfugung steht; 

anschtie3end Senden (310) einer Anforderung 
von dem einen Client an den Netzwerk-Server 
zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebmittel (40. 44); und 

als Reaktion auf die nachfolgende Anforderung 
zum Verbinden mit, oder Zugreifen auf das 
zweite Betriebsmittel (40, 44) Bestimmen (140) 
durch den Netzwerk-Sen/er, dafl einer der 
Femrechner (30, 34) das zweite Betriebsmittel 
venwaltet. Senden (152) einer Anforderung 
vom Netzwerk-Server an den zweiten Fem- 
rechner auf Auf bauen einer Sitzung mit dem er- 
sten Femrechner, wobei diese Anforderung 
den gespeicherten Account-Namen und das 
gespeicherte PaBwort beinhaltet, und Senden 
einer Anforderung auf Verbindung mit. oder Zu- 
griff auf das zweite Betriebsmittel von dem 
Netzwerk-Server zu dem einen Femrechner 

2. Verfahren gema3 Anspruch 1 , f erner enthattend die 
folgenden aufeinanderfolgenden Schritte: 

Senden (340), von dem einen Client (11a-11z) 
an den Netzwerk-Server (14), einer Anforde- 
rung zum Verbinden mit, oder Zugreifen auf, ein 
drittes Betriebsmittel; 

Bestimmen durch den Netzwerk-Sen/er, da3 
ein anderer der Femrechner das dritte Be- 
triebsmittel venwattet; und 

Senden (130). durch den Netzwerk-Sen^er zu 
dem anderen Femrechner, einer Anforderung 
auf Aufbau einer Sitzung, wobei die Sitzungs- 
aufbauanforderung den gespeicherten Ac- 
count-Namen und das gespeicherte PaBwort 
beinhaltet, sowie einer Anforderung auf An- 
schlieBen an, oder Zugriff auf, das dritte Be- 
triebsmittel. 

3. Verfahren gemaB Anspruch 1 oder 2, ferner enthal- 
tend die folgenden Schritte: 

Uberprufen (324, 344) des in der Sitzungsauf- 
bauanforderung enthaltenen Account-Namens 
und des PaBworts durch den einen Femrech- 
ner, und 
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Aufbau (326. 334. 341) der durch den Netz- 
werk-Server angeforderten Sitzung durch den 
Fernrechner. 

4. Verfahren gemaG Anspruch 3. femer enthaltend die s 
folgenden Schhtte: 

Senden, von dem einen Client (11 a-1 1 z) an den 
Netzwerk-Sen/er (14). einer Anforderung zum 
Beenden der Sitzung; 

Bestimmen (202, 204) durch den Netzwerk- 
Server, da3 der eine Fernrechner von der Sit- 
zung betroffen ist; 

15 

Senden (352). durch den Netzwerk-Sen/er an 
den einen Fernrechner. einer Anforderung zum 
Beenden der Sitzung. die vom Netzwerk-Ser- 
ver angefordert wurde; und 

20 

Beenden (208) der Sitzung zwischen dem 
Netzwerk-Server und dem einen Client durch 
den Netzwerk-Sen/er 

5. Verfahren gemaO Anspruch 1 Oder einem der An- ss 
spruche 2 bis 4, ferner enthaltend die folgenden 
Schritte: 

Nach der folgenden Anforderung. Stellen einer 
Anforderung durch ein weiteres Applikations- 30 
programm, das in dem einen Fernrechner ab- 
tauft, auf Zugriff auf das zwette Betriebsmrttel 
(40, 44); und 

gemaQ dem Applikationsprogramm Anforde- ^ 
rung durch dieses andere Applikationspro- 
gramm. das durch diesen einen Fernrechner 
(30, 34) auf das andere Applikationsprogramm 
auf das zweite Betriebsmittel gibt Zugriff. 

40 

6. Verfahren gemaf3 Anspruch 1 Oder einem der An- 
spruche 2 bis 5, in dem die anschtieBende Verbin- 8. 
dungs- Oder Zugrlffsanforderung, die von dem ei- 
nen Client an den Netzwerk-Server gesendet wurde 

( 1 40). das zweite Betriebsmittel mit Namen spezifi- 
ziert, jedoch nicht den einen Fernrechner oder den 
Standort des zwetten Betriebsmittels spezifiziert. 

7. Ein Verfahren zum Venwalten des Zugriffs durch Cti- 9. 
ents (11a-11z) in einem Netzwerk auf ein lokales 50 
Betriebsmittel (24), das von einem Netzwerk-Ser- 
ver (1 4) verwaltet wird. und ein oder mehrere Fern- 
betriebsmittel (40, 44), die von einem oder mehre- 

ren entsprechenden Femrechnern (30, 34) venwal- 
tet werden, logisch und/oder physikalisch gekop- 55 
pelt an den Netzwerk-Server, wobei das Verfahren 
die folgenden Schritte umfaOt: 



Senden (310), von einem der Clients an den 
Netzwerk-Sen/er, einer Anforderung zum Auf- 
bau einer Sitzung, und einer Anforderung zum 
Verbinden mit, oder Zugreifen auf. ein erstes 
Betriebsmittel (40, 44), wobei diese Anforde- 
rungen vorzugsweise durch eine einzige Anfor- 
derung vorgesehen sind, und diese Sitzungs- 
aufbauAnforderung einen Account-Namen und 
ein PaBwort fur den betreffenden einen Client 
enthalt; 

als Reaktion auf die Sitzungsaufbauanforde- 
rung (1 23), Aufbau einer Sitzung mit dem Netz- 
werk-Sen/er, und Speichern (133) des Ac- 
count-Namens und des PaBworts; 

als Reaktion auf die Anforderung zum Verbin- 
den Oder Zugreifen. Bestimmen, daB einer der 
Fernrechner das erste Betriebselement (40, 
44) verwaltet (30, 34), Senden (152) einer An- 
forderung durch den Netzwerk-Sen/er an den 
einen Fernrechner zum Aufbauen einer Sit- 
zung mit diesem einen Fernrechner, wobei die 
Anforderung den gespeicherten Account-Na- 
men und das gespeicherte PaBwort enthalt, 
und Senden einer Anforderung durch den Netz- 
werk-Server an den Fernrechner zum Verbin- 
den mit, Oder Zugreifen auf das erste Betriebs- 
mittel; 

anschlteBend Senden (310) einer Anforderung 
von dem ersten Client an den Netzwerk-Sen/er 
zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebsmittel; und 

als Reaktion auf die nachfolgende Anforde- 
rung. Bestimmen (1 40). daB der Netzwerk-Ser- 
ver das zweite Betriebsmittel venA/altet, und Be- 
stimmen, ob das zweite Betriebsmittel verfug- 
bar ist. 

Verfahren gemaB Anspruch 7, ferner beinhaltend 
den Schritt des Aufbaus der Sitzung mit dem einen 
Fernrechner durch den einen Fernrechner unter 
Uberprufung (324) des Account-Namens und des 
PaBworts als Reaktion auf die Sitzungsaufbauan- 
forderung (152) vom Netzwerk-Server. 

Ein Netzwerk-Sen/er (14) zum Venvalten des Zu- 
griffs durch Clients (11a-1 1z) in einem Netzwerk auf 
ein Oder mehrere vom Netzwerk-Server venwaltete 
lokale Betriebsmittel (24), und ein oder mehrere 
Fernbetriebsmittel (40, 44), die von einem oder 
mehreren entsprechenden Fernrechnern (30, 34) 
venvaltet werden, logisch und/oder physikalisch 
gekoppelt an den Netzwerk-Sen/er, wobei der Netz- 
werk-Sen/er umfaBt: 
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Mittel (52) zum Empfangen, von einem der Cli- 
ents im Netzwerk, einer Anforderung zum Auf- 
bauen einer Sitzung, und einer Anforderung 
zum Verbinden mit, Oder Zugreifen auf ein er- 
stes Betriebsmittel, in dem die Anforderungen 5 
vorzugsweise durch eine einzige Anforderung 
gemacht werden, wobei die Sitzungsaufbauan- 
forderung einen Account-Namen und ein 
Pa3wort fur den einen Client betnhaltet; 

70 

Mittet (53, 54) die auf die Sitzungsaufbauanfor- 
derung reagieren. zum Aufbauen einer Sitzung 
zwischen dem Netzwerk-Server und dem einen 
Client, und zum Speichern des Account-Na- 
mens und des PaBworts; 

MIttel (56), die auf die Anforderung zum Verbin- 
den mit, Oder Zugreifen auf das erste Betriebs- 
mittel reagieren. zum Bestimmen, da3 das er- 
ste Betriebsmittel vom Netzwerk-Sen^er ver- 20 
waltet wird, und zum Bestimmen, ob die Ver- 
bindung fur das erste Betriebsmittel verfugbar 
ist; und 

MIttel (56, 60), die auf eine nachfolgende An- 2S 
forderung von dem einen Client auf Verbindung 
mit. Oder Zugriff zu einem zweiten Betriebsmit- 
tel reagieren, zum Bestimmen. da3 einer der 
Fernrechner das zweite Betriebsmittel verwal- 
tet, Senden einer Anforderung an den einen 30 
Fernrechner zum Auf bau einer Sitzung mit dem 
einen Fernrechner, wobei die Anforderung den 
gespeicherten Account-Namen und das 
PaBwort enthalt, und Senden einer Anforde- 
rung an den einen Fernrechner zum Verbinden 35 
mit, Oder Zugreifen auf das zweite Betriebsmit- 
tel. 

10. Netzwerk-Sen/er gema3 Anspruch 9, in dem: 

40 

Das Bestimmungsmlttel (56) aut eine andere 
Anforderung von dem einen Client auf Verbin- 
den mit, Oder Zugreifen auf ein drittes Betriebs- 
mittel anspricht, zum Bestimmen, daB ein an- 
derer der Fernrechner das dritte Betriebsmittel . 4^ 
verwaltet; und 

das Sendemittel (60) an den anderen Fern- 
rechner eine Anforderung zum Aufbau einer 
Sitzung sendet, diese SItzungsaufbauanforde- so 
rung den gespeicherten Account-Namen und 
das PaBwort sowie eine Anforderung zum Ver- 
binden mit, Oder Zugreifen auf das dritte Be- 
triebsmittel beinhaltet. 

55 

11. Netzwerk-Server gemaB Anspruch 9 Oder 10, fer- 
ner enthaltend: 



Mittel, die auf eine Anforderung von dem einen 
Client zum Beendigen der Sitzung ansprechen, 
zum Bestimmen. daB der eine Fernrechner von 
der Sitzung betroffen ist; 

Mittel (60) zum Senden einer Anforderung auf 
Beenden der vom Netzwerk-Server angefor- 
derten Sitzung an den einen Fernrechner; und 

Mittet zum Beenden der Sitzung zwischen dem 
Netzwerk-Server und dem einen Client. 

1 2. Netzwerk-Server gemaB Anspruch 9, 1 0 Oder 1 1 , in 
dem die nachfolgende Verbindungs- Oder Zugriffs- 
anforderung, die von dem einen Client an den Netz- 
werk-Server gesendet wurde, dieses zweite Be- 
triebsmittel mit Namen spezifiziert. aber nicht den 
einen Fernrechner Oder einen Standort des von 
dem einen Fernrechner verwalteten Betriebsmittels 
spezifiziert. 

13, Ein Netzwerk-Server (14) zum Venwalten des Zu- 
griffs durch Clients (1 1 a-1 1 z) in einem Netzwerk auf 
ein lokales Betriebsmittel (24), das durch einen 
Netzwerk-Server ven/vattet wird, und auf ein oder 
mehrere Fernbetriebsmittel (40, 44), die von einem 
Oder mehreren entsprechenden Fernrechnern (30, 
34) venwaltet werden, die an den Netzwerk-Server 
gekoppelt sind, wobei der Netzwerkserver umfaBt: 

Mittel (52, 53) zum Empfangen, von einem der 
Clients im Netzwerk, einer Anforderung zum 
Aufbau einer Sitzung und einer Anforderung 
zum Verbinden mit, oder Zugreifen auf, ein er- 
stes Betriebsmittel, wobei diese Sitzungsauf- 
bauAnforderung einen Account-Namen und 
ein PaBwort f Or den betreffenden Client enthalt; 

Mittel (54, 60), die auf die Sitzungsaufbauan- 
forderung mit dem Aufbau einer Sitzung hnit 
dem Netzwerk-Sen/er und Speichern des Ac- 
count-Namens und des PaBworts ansprechen; 

Mittel (56), die auf die Anforderung zum Verbin- 
den Oder Zugreifen ansprechen, zum Bestim- 
men, daB einer der Fernrechner das erste Be- 
triebselement venwaltet, Senden einer Anfor- 
derung an den einen Fernrechner zum Aufbau 
einer Sitzung mit dem einen Fernrechner, wo- 
bei die Anforderung den gespeicherten Ac- 
count-Namen und das PaBwort enthalt, und 
Senden einer Anforderung an den Fernrechner 
zum Vertainden mit, oder Zugreifen auf das er- 
ste Betriebsmittel; und 

Mittel (56) die auf die nachfolgende Anforde- 
rung zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebsmittel ansprechen, zum Be- 
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stimmen. da3 der Netzwerk-Server das zweite 
Betriebsmittet verwaltet, und Bestimmen, ob 
das zweite Betriebsmittel vertugbar ist. 

14. Ein Rechnerprogrammprcxiukt zum Verwalten des 
Zugriffs durch Clients (11a-11z) in einem Netzwerk 
auf ein Oder mehrere lokale Betriebsnnittel (24), die 
von einem Netzwerk-Server (14) verwaltet werden,, 
und ein Oder mehrere Fernbetriebsmittel (40, 44), 
die von einem Oder mehreren entsprechenden 
Fernrechnern (30, 34) verwaltet werden, logisch 
und/oder physikalisch gekoppelt an den Netzwerk- 
Server, wobei das Rechnerprogrammprodukt um- 
fa6t: 

ein Rechner-lesbares Medium; 

erste Programmanweisungsmittel, die auf dem 
Medium autgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors zum Empfangen einer 
Anforderung von einem der Clients oder vom 
Netzwerk zum Aufbau einer Sitzung. und einer 
Anforderung zum Verbinden mit. oder Zugrei- 
fen auf ein erstes Betriebsmittel, wobei die Sit- 
zungsaufbauanforderung einen Account-Na- 
men und ein PaGwort fur den einen Client ent- 
halt; 

zweite Programmanweisungsmittel, die auf 
dem Medium autgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors. auf die Sit- 
zungsaufbauanforderung zu reagieren mit dem 
Aufbau einer Sitzung zwischen dem Netzwerk- 
Server und dem Client, und Abspeichem des 
Account-Namens und des PaRworts; 

dritte Programmanweisungsmittel, die auf dem 
Medium autgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors. auf die Anforderung 
zum Verbinden mit, oder zum Zugreifen auf das 
erste Betriebsmittel, zu reagieren durch Be- 
stimmen, da3 das erste Betriebsmittel vom 
Netzwerk-Server verwaltet wird, und Bestim- 
men. ob die Verbindung zum ersten Betriebs- 
mittel verfugbar ist; 

vierte Programmanweisungsmittel, die auf dem 
Medium autgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf die Anforderung 
von dem einen Client zum Verbinden mit, oder 
Zugreifen auf das zweite Betriebsmittel, zu rea- 
gieren durch Bestimmen, daO einer der Fern- 
rechner das zweite Betriebsmittel verwaltet, 
durch Senden einer Anforderung an den Fern- 
rechner zum Autbauen einer Sitzung mit dem 
einen Fernrechner, wobei die Anforderung den 
gespeicherten Account-Namen und das 
PaGwort beinhaltet. und Senden einer Anf orde- 
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rung an den einen Fernrechner zum Verbinden 
mit, Oder Zugreifen auf das zweite Betriebsmit- 
tel; und 

in dem jedes dieser Programmanweisungsmit- 
tel durch den zugeordneten Rechnerprozessor 
ausfuhrbar ist. 

15. Ein Rechnerprogrammprodukt gemaB Anspruch 
14, in dem 

das drrtte Programmanweisungsmittel auf eine 
weitere Anforderung von dem einen Client zum 
Verbinden mit, oder Zugreifen auf ein drittes 
Betriebsmittel reagiert, durch Anweisen eines 
Rechnerprozessors zum Bestimmen, da3 ein 
anderer dieser Fernrechner das dritte Betriebs- 
mittel venwaltet; und 

das vierte Programmanweisungsmittel einen 
Rechnerprozessor anweist, an diesen anderen 
Femrechner eine Anforderung zu senden. um 
eine Sitzung aufzubauen, wobei diese Sit- 
zungsaufbauanforderung den gespeicherten 
Account-Namen und das PaGwort und eine An- 
forderung beinhaltet, sich mit dem dritten Be- 
triebsmittel zu verbinden oder darauf zuzugrei- 
fen. 

16. Ein Rechnerprogrammprodukt gemaG Anspruch 1 4 
Oder 15, das ferner enthalt: 

funfte Programmanweisungsmittel, die auf 
dem Medium autgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, auf eine Anfor- 
derung des einen Client zum Beenden der Sit- 
zung zu reagieren, um zu bestimmen, daG der 
eine Femrechner von der Sitzung betroffen ist; 

sechste Programmanweisungsmittel, die auf 
dem Medium autgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, an den einen 
Femrechner eine Anforderung zum Beenden 
der von dem einen Netzwerk-Sen^er angefor- 
derten Sitzung zu senden; und 

siebte Programmanweisungsmittel, die auf 
dem Medium autgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, die Sitzung zwi- 
schen dem Netzwerk-Server und dem einen 
Client zu beenden; und worin das funfte, sech- 
ste und siebte Programmanweisungsmittel 
durch den zugeordneten Rechnerprozessor 
ausfuhrbar ist. 

17. Ein Rechnerprogrammprodukt gemaG Anspruch 
14, 15 Oder 16, in dem die anschlieGend von dem 
einen Client gesendete Verbindungs- oder Zugriffs- 
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anforderung das zweite Betriebsmittel mlt dem Na- 
men spezifiziert, jedoch nichtden Fernrechneroder 
eine Adresse des Betriebsmittels spezifiziert, das 
der eine Fernrechner verwaltet. 

18. Ein Rechnerprogrammprodukt zum Verwalten des 
Zughffs durch Clients in einem Netzwerk auf ein lo- 
kales Betriebsmittel, das vom Netzwerk-Server ver- 
waltet wird, und ein Oder mehrere Fembetriebsmit- 
tel, die von einem oder mehreren entsprechenden 
Fernrechner verwaltet werden, wobei das Rechner- 
produkt enthalt: 

erste Programmanweisungsmittel. die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors zum Empfangen einer 
Anforderung von einem dieser Clients auf dem 
Netzwerk zum Aufbau einer Sitzung, und etner 
Anforderung zum Verbinden mit, oder Zugrel- 
f en auf ein erstes Betriebsmittel, wobei die Sit- 
zungsaufbauanforderung einen Account-Na- 
men und ein PaBwort fur diesen einen Clienten 
beinhaltet; 

zweite Programmanweisungsmittel, die auf 
dem Medium aufgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors. auf die Sit- 
zungsaufbauanforderung durch Aufbau einer 
Sitzung mit dem Netzwerk-Server und Spei- 
chem des Account-Namens und des PaBworts 
zu reagieren; 

dritte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf die Verbindungs- 
oder Zugriffsaufforderung zu reagieren durch 
Bestimmen, daB einer der Fernrechner das er- 
ste Betriebsmittel verwaltet, durch Senden ei- 
ner Anforderung an den einen Fernrechner, ei- 
ne Sitzung mit dem einen Fernrechner aufzu- 
bauen, wobei die Anforderung einen abgespei- 
cherten Account-Namen und ein PaBwort be- 
inhaltet, und Senden einer Anforderung an den 
Fernrechner, um mit dem ersten Betriebsmittel 
verbunden zu werden oder darauf Zugriff zu 
nehmen; und 

vierte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf eine nachfolgen- 
de Anforderung zum Verbinden mit. oder Zu- 
griff auf ein zweites Betriebsmittel zu nehmen. 
zu reagieren durch Feststellung, daB der Netz- 
werk-Server das zweite Betriebsmittel verwal- 
tet. und Bestimmen, obdas zweite Betriebsmit- 
tel verfugbar ist; und in dem jedes der Pro- 
grammanweisungsmittel durch den beigeord- 
neten Rechnerprozessor ausfuhrbar ist. 



Revendlcations 

1. Proc6d6 destine k g6rer des acc^s par des clients 
(11a& 11z) dans un r6seau k uneou plusieurs res- 

5 sources locales (24) g6r6es par un sen/eur de r6- 
seau (1 4) et une ou plusieurs ressources ^ distance 
(40, 44) gardes par un ou plusieurs ordinateurs k 
distance respectifs (30, 34) logiquement et/ou phy- 
stquement relics au serveur de r^seau, ledit proc6- 

10 d§ comprenant les stapes consistant k : 

envoyer (310) depuis Tun desdits clients audit 
sen^eur de r^seau. une demande pour dtablir 
une session et une demande pour se connecter 

t5 ou accdder k une premiere ressource (24), 

dans lequel lesdites demandes sont de pr6fd- 
rence fournies grdce k une demande unique, 
ladite demande d'dtablissement de session 
comprenant un nom de compte et un mot de 

20 passe pour ledit un client, 

en r^ponse k la demande d'dtablissement de 
session (123), dtablir par ledit serveur de r^- 
seau une session entre ledit serveur de r^seau 
25 et tedit client, et m^moriser (133) lesdits nom 

de compte et mot de passe, 

en r^ponse k la dennande pour se connecter ou 
acc^der k ladite premiere ressource, d^termi- 
30 ner que ladite premiere ressource est g^r^e par 

ledit sen/eur de rdseau, et determiner si ladite 
connexion est disponlble pour ladite premiere 
ressource (24), 

35 ensuite, envoyer (310) depuis ledit un client 

vers ledit serveur de r^seau, une demande 
pour se connecter ou accdder k une seconde 
ressource (40, 44), et 

40 en rdponse k ladite demande suivante pour se 

connecter ou accdder k ladite seconde res- 
source (40, 44), determiner (140) par ledit ser- 
veur de rdseau que I'un desdits ordinateurs k 
distance (30, 34) g^re ladite seconde ressour- 

45 ce, envoyer (152) une demande par ledit ser- 

veur de r^seau vers ledit un ordinateur k dis- 
tance aftn d'etablir une session avec ledit un or- 
dinateur k distance, ladite demande compre- 
nant lesdits nom de compte et mot de passe 

so memorises, et envoyer une demande par ledit 

serveur de r^seau audit un ordinateur k distan- 
ce afin de se connecter ou d'acc^der k ladite 
seconde ressource nomm6e. 

55 2, Proc6d6 selon la revendication 1 , comprenant en 
outre les Stapes suivantes consistant k : 

envoyer (340) depuis ledit un client (11a^ 11z) 
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audit serveur de r6seau (14) une demande 
pour se connecter ou acc6der h une troisi6me 
ressource, 

ddterminer par ledit serveur de r6seau qu'un 
autre desdits ordinateurs ^ distance gdre ladite 
troisi6me ressource, et 

envoyer (1 30) par ledit serveur de r^seau audit 
autre ordinateur k distance une denriande pour 
^tablir une session, ladite demande d'^tablis- 
sement de session comprenant lesdits nom de 
compte et mot de passe mdmoris^s, et une de- 
mande pour se connecter ou accede r k ladite 
trolsi^me ressource. 

3. Proc6d6 selon la revendication 1 ou 2, comprenant 
en outre les dtapes consistant k : 

valider (324, 344) par (edit un ordinateur k dis- 
tance lesdits nom de compte et mot de passe 
inclus dans ladite demande d'6tablissement de 
session, et 

dtablir (326, 334, 341) par ledit un ordinateur k 
distance ladite session demand^e par ledit ser- 
veur de r^seau. 

4. Proc6d6 selon la revendication 3 comprenant en 
outre les stapes consistant k : 

envoyer depuis ledit un client (11a ^ 11z) audit 
serveur de rdseau (1 4) une demande pour met- 
tre fin k tadite session, 

d6terminer (202, 204) par ledit sen/eur de r6- 
seau que ledit un ordinateur k distance est im- 
pliqu^ dans ladite session, 

envoyer (352) par ledit sen/eur de r^seau audit 
un ordinateur k distance une demande pour 
mettre fin k ladite session demand6e par ledit 
serveur de rdseau, et 

mettre fin (208) par ledit serveur de rdseau k la 
session entre ledit serveur de r^seau et ledit un 
client. 

5. Proc^d^ selon la revendication 1 ou I'une des re- 
vendications 2^4, comprenant en outre les dtapes 
consistant k : 

apr6s ladite demande suivante, effectuer une 
demande par un autre programme d'applica- 
tion s'ex^cutant k Tintdrieur dudit un ordinateur 
k distance en vue d'acc^der k ladite seconde 
ressource (40, 44), et 



envoyer (310) depuis fun desdits clients audit 
serveur de r^seau une demande en vue d'6ta- 
blir une session et une demande pour se con- 
necter ou acc6der k une premiere ressource 
(40, 44), dans lequel tesdites demandes sont 
de pr6f6rence r6alis6es grSce k une demande 
unique, ladite demande d'^tablissement de 
session comprenant un nom de compte et un 
mot de passe pour ledit un client. 

en rdponse k la demande d'dtablissement de 
session (123), 6tablir par ledit sen/eur de r§- 
seau une session avec ledit serveur de r^seau. 
et m6moriser (133) lesdits nom de compte et 
mot de passe, 

en r6ponse k la demande de connexion ou 
d'acc6s, determiner que Tun desdits ordina- 
teurs k distance g^re (30, 34) ladite premiere 
ressource (40, 44), envoyer (152) une deman- 
de par ledit sen/eur de r^seau audit un ordina- 
teur k distance afin d'^tablir une session avec 
ledit un ordinateur k distance, ladite demande 
comprenant lesdits nom de compte et mot de 
passe mdmoris^s, et envoyer une demande 
par ledit sen^eur de r^seau audit ordinateur k 
distance pour se connecter ou acc^der k ladite 
premiere ressource, 

ensuite. envoyer (310) depuis ledit un client 
audit serveur de r^seau une demande pour se 
55 connecter ou acc6der k une seconde ressour- 

ce, et 

en r^ponse k ladite demande suivante, ddter- 



k la suite de tadite demande de programme 
d*application par ledit autre programme d'appli- 
cation, r^aliser un acc^s par ledit un ordinateur 
k distance (30, 34) audit autre programme d'ap- 
5 plication sur ladite seconde ressource. 

6. Proc6d6 selon la revendication 1 ou I'une des re- 
vendications 2^5, dans lequel la demande de con- 
nexion ou d'accds suivante envoyde (140) par ledit 
10 un client audit serveur de r^seau sp^ctfie ladite se- 
conde ressource par un nom, mais ne sp6cifie pas 
ledit un ordinateur k distance ni I'emplacement de 
ladite seconde ressource. 

15 7. Proc6d6 destine k g6rer des acc6s par des clients 
(11a ^ 11z) dans un rdseau k une ressource locale 
(24) g6r6e par un serveur de r^seau (1 4) et une ou 
plusteurs ressources k distance (40. 440) gdrdes 
par un ou plusieurs ordinateurs k distance respec- 

20 tifs (30, 34) logiquement et/ou physiquement relics 
au sen^eur de rdseau, ledit proc^dd comprenant tes 
etapes consistant k : 
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miner (140) que ledit serveur de r6seau g6re 
ladite seconde ressource, et determiner si ladi- 
te seconde ressource est disponible. 

8. Proc6d6 se!on la revendication 7, comprenant en s 
outre retape consistant k dtablir ladite session avec 
ledit un ordinateur k distance en faisant valider par 
ledit un ordinateur k distance (324) lesdits nom de 
compte et mot de passe, en rdponse k ladite de- 
mande d'6tablissement de session (152) provenant 
dudit serveur de r6seau. 

9. Serveur de rdseau (14) destine k gdrer des accds 
par des clients (11a ^ 11 z) dans un r^seau k une 

ou plusieurs ressources locales (24) g6r6es par le- '5 
. dit serveur de rdseau et une ou plusieurs ressour- 
ces k distance (40, 44) gardes par un ou plusieurs 
ordinateurs k distance respectifs (30, 34) togique- 
ment et/ou phystquement relics au serveur de r6- 
seau, ledit serveur de r6seau comprenant : 20 

un moyen (52) destin6 k recevoir de I'un desdits 
clients sur ledit rdseau une demande pour 6Xa- 
blir une session et une demande pour se con- 
necter ou accdder k une premiere ressource, 2S 
dans leque) lesdites demandes sont de prefe- 
rence rdalisees par une demande unique, ta 
demande d'etabllssement de session compre- 
nant un nom de compte et un mot de passe 
pour ledit un client. 30 

un moyen (53, 54) r^pondant k la demande 
d'etablissement de session, en vue d'etablir 
une session entre ledit sen/eurde r^seau et le- 
dit un client, et m6moriser lesdits nom de comp- 3S 
te et mot de passe, 

un moyen (56), repondant k la demande pour 
se connecter ou accdder k ladite premiere res- 
source, afin de determiner que ladite premiere 40 
ressource est geree par ledit sen/eur de re- 
seau, et determiner si ladite connexion est dis- 
ponible k ladite premiere ressource, et 

un moyen (56, 60) repondant ^ une demande 45 
suivante provenant dudit un client pour se con- 
necter ou pour acceder ^ une seconde ressour- 
ce, afin de determiner que I'un desdits ordina- 
teurs k distance gere ladite seconde ressource, 
envoyer une demande audit un ordinateur k 
distance afin d'etablir une session avec ledit un 
ordinateur k distance, ladite demande compre- 
nant lesdits nom de compte et mot de passe 
memorises, et envoyer une demande audit un 
ordinateur k distance pour se connecter ou ac- s$ 
ceder k ladite seconde ressource. 

10. Serveur de reseau selon la revendication 9. dans 



lequel : 

!e moyen de determination (56) repond k une 
autre demande provenant dudit un client pour 
se connecter ou pour acc6der k une troisieme 
ressource afin de determiner qu'un autre des- 
dits ordinateurs k distance gere ladite troisieme 
ressource, et 

le moyen d'envoi (60) envoie audit autre ordi- 
nateur k distance une demande pour etablir 
une session, ladite demande d'etabltssement 
de session comprenant lesdits nom de compte 
et mot de passe memorises, et une demande 
pour se connecter ou pour acceder k ladite troi- 
sieme ressource. 

11. Serveur de reseau selon la revendication 9 ou 10, 
comprenant en outre : 

un moyen, repondant k une demande prove- 
nant dudit un client pour mettre fin k ladite ses- 
sion, en vue de determiner que ledit un ordina- 
teur k distance est implique dans ladite ses- 
sion, 

un moyen (60) destine k envoyer audit un ordi- 
nateur k distance une demande pour mettre fin 
k ladite session demandee par ledit serveur de 
reseau, et 

un moyen destine k mettre fin k la session entre 
ledit serveur de reseau et ledit un client. 

12. Serveur de reseau selon la revendication 9, 10 ou 
11 , dans lequet la demande de connexion ou d'ac- 
ces suivante emise par ledit un client vers ledit ser- 
veur de reseau specifie ladite seconde ressource 
par un nom, mais ne specifie pas ledit un ordinateur 
k distance ni un emplacement de la ressource ge- 
ree audit un ordinateur k distance. 

13. Serveur de reseau (14) destine k gerer un acces 
par des clients (11a ^ 11 z) dans un reseau k une 
ressource locale (24) geree par le serveur de re- 
seau et une ou plusieurs ressources k distance (40, 
44) gerees par un ou plusieurs ordinateurs k distan- 
ce respectifs (30, 34) relies au serveur de reseau, 
ledit serveur de reseau comprenant : 

un moyen (52, 53) destine k recevoir de I'un 
desdits clients sur ledit reseau, une demande 
en vue d'etablir une session et une demande 
pour se connecter ou pour acceder k une pre- 
miere ressource, la demande d'etablissement 
de session comprenant un nom de compte et 
un mot de passe pour ledit un client, 
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un moyen (54, 60) r6pondant k la demands 
d'dtablissement de session, afin d'dtablir une 
session avec tedit serveurde r^seau, at m^mo- 
riser lesdits nom de compte et mot de passe. 

5 

un moyen (56), r6pondant k la demande de 
connexion ou d'acc^s, afin de d^temniner que 
I'un desdits ordinateurs k distance gdre ladite 
premiere ressource, envoyer une demande 
audit un ordinateur k distance afin d'dtablir une 
session avec ledit un ordinateur k distance, la- 
dite demande comprenant lesdits nom de 
compte et motde passe m6moris6s, et envoyer 
une demande audit ordinateur k distance pour 
se connecter ou pour acc^der k ladite premiere 
ressource, et 

un moyen (56), rdpondant k une demande sui- 
vante pour se connecter ou acc6der k une se- 
conds ressource, afin de determiner que ledit 20 
serveurde r6seau g6re ladite seconde ressour- 
ce, et determiner si ladite seconde ressource 
est disponible. 



1 4. Produit de programme inf ormatique destind k g6rer 25 
des acc6s par des clients (11a k 11z) dans un r^- 
seau k une ou plusieurs ressources locales (24) ga- 
rdes par le serveur de r^seau (14) et une ou plu- 
sieurs ressources k distance (40, 44) gdr^es par un 
ou plusieurs ordinateurs k distance respectifs (30, 30 
34) logiquement et/ou physiquement reli6s au ser- 
veur de r^seau, ledit produit de programme infor- 
matique comprenant ; 

un support lisible par un ordinateur, 3S 

des premiers moyens d'instruction de program- 
me, enregistrds sur ledit support, en vue de 
donner pour instruction k un processeur d'ordi- 
nateur de recevoir de t'un dudit client ou dudit ^^o 
rdseau une demande en vue d'^tablir une ses- 
sion et une demande pour se connecter ou pour 
accdder k une premiere ressource, la demande 
d'^tablissement de session comprenant un 
nom de compte et un mot de passe pour ledit 45 
un client, 

des seconds moyens d'instruction de program- 
me, enregistr^s sur tedit support, en vue de 
donner pour instruction k un processeur d'ordi- 
nateur de rdpondre k la demande d'^tablisse- 
ment de session, en 6tablissant une session 
entre ledit serveur de r^seau et ledit client, et 
m6moriser lesdits nom de compte et mot de 
passe, 55 

des trotstdmes moyens d'instruction de pro- 
gramme, enregistr6s sur ledit support, en vue 



de donner pour instruction k un processeur 
d'ordinateur de r^pondre k la demande pour se 
connecter ou pour acc^der k ladite premiere 
ressource, en determinant que ladite premiere 
ressource est g^r^e par ledit serveur de rd- 
seau, et en determinant si ladite connexion est 
disponible k ladite premiere ressource, et 

des quatriemes moyens d'instruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction k un processeur 
d'ordinateur de rdpondre k une demande sui- 
vante provenant dudit un client pour se connec- 
ter ou acceder k une seconde ressource, en de- 
terminant que i'un desdits ordinateurs k distan- 
ce gere ladite seconde ressource, envoyer une 
demande audit un ordinateur k distance pour 
etabiir une session avec ledit un ordinateur k 
distance, ladite demande comprenant lesdits 
nom de compte et mot de passe memorises, et 
envoyer une demande audit un ordinateur k 
distance pour se connecter ou acceder k ladite 
seconde ressource, et 

dans lequel chacun desdits moyens d'instruc- 
tion de programme est executable par le pro- 
cesseur d'ordinateur associe. 

15. Produit de programme informatique selon la reven- 
dication 14, dans lequel 

ies troisiemes moyens d'instruction de pro- 
gramme repondent k une autre demande pro- 
venant dudit un client pour se connecter ou ac- 
ceder k une troisieme ressource en donnant 
pour instruction k un processeur d'ordinateur 
de determiner qu'un autre desdits ordinateurs 
k distance gere ladite troisieme ressource, et 

Ies quatriemes moyens d'instruction de pro- 
gramme donnent pour instruction k un proces- 
seur d'ordinateur d' envoyer audit autre ordina- 
teur k distance une demande en vue d'etablir 
une session, ladite demande d'etablissement 
de session comprenant lesdits nom de compte 
et mot de passe memorises, et une demande 
pour se connecter ou acceder k ladite troisieme 
ressource. 

16. Produit de programme inf ormatique selon la reven- 
dication 14 ou 15, comprenant en outre : 

des cinquiemes moyens d'instruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction k un processeur 
d'ordinateur de repondre k une demande pro- 
venant dudit un client pour mettre fin k ladite 
session, afin de determiner que ledit un ordina- 
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42 



teur ^ distance est impliqud dans tadite ses- 
sion. 

des sixi6mes moyens d'instruction de program- 
me, enregistr6s sur iedrt support, afin de don- s 
ner pour instruction ^ un processeur d'ordina- 
teur d'envoyer audit un ordinateur k distance 
une demande pour mettre fin k ladite session 
demandde par ledit sen/eur de r6seau, et 

10 

des septi6mes moyens d'instruction de pro- 
gramme, enregistr^s sur ledit support, en vue 
de donner pour instruction k un processeur 
d'ordinateur de mettre fin k la session entre le- 
dit sen/eur de r^seau et ledit un client, et dans 
lequel ledit cinqui^me, sixidme et septi^me 
moyens d'instruction de programme sont ex6- 
cutables par le processeur d'ordinateur asso- 

20 

17, Produit de programme informatique selon !a reven- 
dication 14, 15 ou 16, dans lequel la demande de 
connexion ou d'acc^s suivante 6mlse par (edit un 
client sp6cif ie ladite seconde ressource par un nom, 
mais ne sp^cifie pas ledit un ordinateur k distance 25 
ni une adresse de la ressource g^ree audit un ordi- 
nateur k distance. 

1 8, Produit de programme informatique destind k g6rer 

un acc^s par des clients dans un r^seau k un res- 30 
source locale g^r^e par le sen/eur de r^seau et une 
ou plusieurs ressources k distance gardes par un 
ou plusieurs ordinateurs k distance respectifs relics 
au serveur de r6seau, ledit produit de programme 
informatique comprenant : 55 

des premiers moyens d'instruction de program- 
me, enregistr^s sur ledit support, en vue de 
donner pour instruction k un processeur d'ordi- 
nateur de recevoir de I'un desdits clients sur le- 
dit.rdseau une demande pour dtablir une ses- 
sion et une demande pour se connecter ou ac- 
c^der k une premiere ressource, ta demande 
d'^tablissement de session comprenant un 
nom de compte et un mot de passe pour ledit 
un client, 

des seconds moyens d'instruction de program- 
me, enregistr^s sur ledit support, en vue de 
donner pour instruction k un processeur d'ordi- so 
nateur de rdpondre k la demande d'6tablisse- 
ment de session en dtablissant une session 
avec ledit serveur de r6seau. et en m6morisant 
lesdits nom de compte et mot de passe, 

55 

des troisidmes moyens d'instruction de pro- 
gramme, enregistrds sur ledit support, en vue 
de donner pour instruction k un processeur 



d'ordinateur de r^pondre k la demande de con- 
nexion ou d'acc^s en determinant que Tun des- 
dits ordinateurs k distance gdre ladite premiere 
ressource, envoyer une demande audit un or- 
dinateur k distance pour dtablir une session 
avec ledit un ordinateur k distance, ladite de- 
mande comprenant lesdits nom de compte et 
mot de passe m6moris6s, et envoyer une de- 
mande audit ordinateur k distance pour se con- 
necter ou acc^der k ladite premiere ressource, 
et 

des quatri6mes moyens d'instruction de pro- 
gramme, enregistrds sur ledit support, en vue 
de donner pour instruction k un processeur 
d'ordinateur de rdpondre k une demande sui- 
vante pour se connecter ou acc6der k une se- 
conde ressource en determinant que ledit ser- 
veur de r^seau g^re ladite seconde ressource, 
et determiner si ladite seconde ressource est 
disponible. et dans lequel 

chacun desdits moyens d'instruction de pro- 
gramme est executable par le processeur d'or- 
dinateur assocte. 
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